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BACKGROUND: 

In  2003  the  Department  of  Defense  (DoD)  began  transfonning  the  methodology 
for  modernizing  military  forces.  For  many  years,  the  DoD  had  used  a  top-to-bottom  force 
structure  planning  process  based  on  a  set  of  planning  scenarios  developed  from  National 
Military  Strategy,  Unified  Command  War  Plans,  and  expected  future  threats  provided  by 
the  Intelligence  Community.  This  part  of  modernization  planning  accounted  for  doctrine, 
organization,  training,  leadership,  and,  in  part,  for  facilities.  Modernization  planning  had 
previously  been  a  stovepipe  process  whereby  each  functional  area  was  responsible  for 
modernization  planning  for  the  material  means  and  supporting  facilities,  using  different 
evaluations  of  the  expected  future  threats.  The  acquisition  process  was  more  narrowly 
focused  on  developing  specific  systems,  which  were  based  on  bottom-up  specified 
requirements.  These  requirements  were  based  on  scenario-specific  threats  and  included 
system-unique  specifications  derived  to  counter  these  threats.  But  the  international 
security  environment  has  changed  —  and  it  will  continue  to  change. 

This  new  environment  led  the  DoD  to  transform  the  planning  and  modernization 
processes.  Additionally,  the  force  planning,  functional  area  planning  and  acquisition 
processes  (described  above)  were  found  to  have  some  downsides.  First,  manpower 
requirements  were  driven  at  least  as  much  by  system  manning  requirements  as  by 
requirements  derived  from  the  force  structure  planning  process.  Second,  modernization 
planning  in  one  functional  area  often  impacted  modernization  planning  in  other 
functional  areas,  without  providing  any  indication  of  those  interdependencies.  The  effect 
was  to  provide  no  insight  as  to  the  total  cost  of  ownership  for  new-development 
initiatives.  Additionally,  the  stovepiped  functional  area  planning  process  provided  no 
opportunity  for  combat  support  functional  areas  to  show  their  value,  or  lack  of  value,  to 
combat  capability.  Finally,  each  modernization  process  (force  structure  planning, 
functional  area  planning,  and  acquisition)  had  its  own  vocabulary,  thus  making  it  difficult 
to  integrate  the  goals  and  outcomes  of  these  processes. 
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In  response  to  the  changes  in  the  world  environment,  the  DoD  has  adopted  an 
integrated  top-down  capabilities-based  planning  and  assessment  methodology  in  response 
to  the  shortcomings  in  the  previous  modernization  process.  This  new  methodology 
includes  a  concept  development  process,  a  capabilities-based  assessment  process  for 
developmental  capabilities,  a  Doctrine,  Organization,  Training,  Material,  Leadership, 
Personnel,  Facilities  (DOTMLPF)  requirements  process  for  non-developmental  capability 
changes,  and  a  new  capabilities-based  acquisition  process. 

Capabilities-based  planning  begins  with  the  concept  development  process  (Joint 
Concept  Development  and  Revision  Plan)  including  development  of  effects-based  Joint 
Operations  Concepts  (JOC)  and  Joint  Functional  Concepts  (JFC)  which  describe  planned 
future  capabilities.  The  Joint  Concept  Development  and  Revision  Plan  defines  a 
capability  as,  “the  ability  to  achieve  an  effect  to  a  standard  under  specified  conditions 
through  multiple  combinations  of  means  and  ways  to  perform  a  set  of  tasks.”  Finally,  the 
process  includes  Joint  Integrating  Concepts  (JIC)  which  couple  one  or  more  JOCs  to  one 
or  more  JFCs.  The  JICs  identify  the  capability  tasks  with  the  associated  performance 
standards  needed  to  achieve  one  or  more  specific  effects.  The  capabilities,  associated 
tasks  and  perfonnance  standards  serve  as  the  input  to  the  processes  that  establish  new 
capabilities. 


The  first  step  in  establishing  new  capabilities  is  to  evaluate  potential  non- 
developmental  changes  in  DOTMLPF  (CJCSI  3180.01).  If  non-developmental  changes  in 
DOTMLPF  do  not  satisfy  (or  only  partially  satisfy)  new  capability  needs,  then  a 
Capabilities-Based  Assessment  (CBA)  is  begun. 

The  Capabilities-Based  Assessment  process  is  defined  by  the  Joint  Capabilities 
Integration  and  Development  System  (JCIDS)  in  the  CJCS  3170  series  documents.  This 
process  is  now  being  used  to  determine  the  system  requirements  for  the  DoD  Net-Centric 
Operating  Environment  (NCOE).  A  principal  feature  of  the  planned  NCOE  CBA  is  the 
maximum  possible  use  of  modeling  and  simulation  (M&S)  in  support  of  analysis. 

In  general,  a  CBA  encompasses  three  major  phases: 

•  The  Functional  Area  Analysis  (FAA):  The  FAA  characterizes  a  particular 
military  arena  in  terms  of  the  operations  that  are  required  to  be  performed. 

The  FAA  identifies  the  operational  tasks,  conditions  and  standards  needed  to 
achieve  military  objectives. 

•  The  Functional  Needs  Assessment  (FNA):  The  FNA  assesses  the  ability  of  the 
current  and  programmed  warfighting  systems  to  deliver  the  capabilities 
identified  in  the  FAA.  The  FNA  considers  the  full  range  of  operating 
conditions  against  specific  measures  of  effectiveness. 

•  The  Functional  Solutions  Analysis  (FSA):  The  FSA  is  an  operationally-based 
assessment  of  all  potential  DOTMLPF  and  policy  approaches  to  solving  (or 
mitigating)  one  or  more  of  the  capability  gaps  identified  in  the  FNA. 
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Finally,  the  outcome  of  the  FSA  becomes  the  input  to  the  acquisition  process.  The  new 
acquisition  process  (DoDI  5000.2)  is  designed  to  align  with  the  top-down  capabilities- 
based  planning  and  assessment  methodology. 


OBJECTIVE: 

The  objective  of  this  project,  conducted  under  the  sponsorship  of  the  Net  Centric 
Capabilities  Division  (J6A)  of  the  Joint  Chiefs  of  Staff,  is  to  define  an  architecture-based 
process  as  a  rigorous  and  repeatable  tool  that  can  support  the  capabilities-based  planning, 
assessment  and  acquisition  processes  described  above. 

The  process  will  be  tested  by  direct  application  to  the  real-world  problem  of  the 
NCOE  CBA.  Using  this  architecture-based  process,  MITRE  will  identify  the 
architectural  data  objects  needed  to  provide  a  complete  audit  trail  from  a  selected  military 
command  and  control  example  down  to  the  underlying  net-centric  capabilities  needed  to 
support  it.  This  explicit  identification  of  data  objects  and  their  relationships  should  then 
facilitate  modeling  and  simulation  analyses  to  be  conducted  in  support  of  the  CBA. 

DISCUSSION: 

Though  the  guiding  document  for  the  conduct  of  CBAs,  CJCSI  3 170.01E, 
specifies  for  the  use  of  “integrated  architectures”  as  part  of  the  process,  the  document 
provides  no  insight  into  what  constitutes  an  “integrated  architecture,”  leaving  the  reader 
to  turn  to  DoD  Architecture  Framework  (DoDAF),  Ver  1.0,  for  further  guidance  and 
direction.  Unfortunately,  DoDAF  focuses  on  information  technology  and  the  means  by 
which  architecture  should  be  “presented”  -  and  not  on  how  it  should  be  developed  or 
used. 


Furthermore,  since  the  JCIDS  process  is  a  relatively  new  development  in  the 
DoD,  only  a  few  CBAs  have  been  conducted  to  date.  These  have  been  performed  by 
different  teams,  each  of  which  has  had  to  make  their  own  determination  of  what 
constitutes  an  “integrated  architecture.”  Consequently,  each  team  developed  architecture 
its  own  way,  applying  “unique”  approaches  to  performing  associated  analyses.  The 
resulting  architectures  vary  considerably  in  terms  of  form  and  content,  and  the  analytical 
techniques  employed  also  differ;  some  are  quite  infonnal,  while  others  reflect  only  the 
judgments  of  a  particular  team. 

The  bottom  line  is  that  a  more  rigorous  and  repeatable  process  would  facilitate  the 
application  of  architectures  in  support  of  the  NCOE  CBA  and  to  support  the  concurrent 
use  of  modeling  and  simulation  techniques. 

An  effective  CBA  requires  three  things: 

•  identification  of  the  various  components  of  military  operations  and  their 
supporting  capabilities, 
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•  understanding  of  the  relationships  among  those  components,  and 

•  the  use  of  modeling  and  simulation  (M&S)  tools  to  incorporate  that 
understanding  while  assessing  and  comparing  alternative  solutions  to  meet 
operational  needs. 

To  provide  them,  the  authors  propose  a  rigorous  approach  to  conducting  CBAs 
that  explicitly  identifies: 

•  the  individual  components  of  an  integrated  architecture  and  their 
relationships,  and 

•  a  logical  analytical  flow  from  the  military  operations  that  need  to  be 
conducted  down  to  the  supporting  capabilities  needed  to  enable  the 
military  operations. 

The  detailing  of  each  component  and  the  relationships  among  components 
provides  a  sound  basis  for  the  logical  construction  of  models  that  represent  the  integrated 
architecture  and  helps  to  highlight  factors  and  relationships  that  need  to  be  simulated  as 
part  of  the  CBA  process. 

The  current  DoDAF  does  not  adapt  well  to  the  capability-based  planning  process, 
in  large  part,  due  to  object  class  limitations  and  the  inability  to  render  the  architectural 
data  in  a  way  that  is  useful  to  many  of  the  governance  process  leaders.  The  Concept 
Development  and  JCIDS  processes  describe  the  following  key  entities  (or  object  classes): 
effect,  capability,  task,  attribute,  condition,  measure  and  criterion.  With  the  exception  of 
tasks  (activities  in  DoDAF),  these  entities  are  not  described  in  the  DoDAF.  This 
limitation  and  other  shortfalls  in  DoDAF  led  the  MITRE  Corporation  to  begin 
development  of  the  Architecture  Specification  Model  (ASM). 1  As  depicted  in  Figure  1, 
the  ASM  is  aimed  at  relating  architecture  objects  to  the  six  basic  interrogatives  that  can 
be  used  to  address  all  the  dimensions  of  an  architecture:  who,  what,  when,  where,  how, 
and  why.  As  such  the  ASM  describes  a  much  broader  set  of  architectural  objects  and 
attempts  to  explicitly  show  the  relationships  among  them.  These  objects  may  then  be 
rendered  into  any  view  that  best  suits  the  type  of  analysis  and  preferences  of  the  intended 
user. 


1  The  Architecture  Specification  Model  has  been  the  result  of  the  collaborative  efforts  of  Mr.  David 
Nicholson,  Mr.  Bradford  Mercer,  and  Ms.  Huei-Wan  Ang  of  the  MITRE  Corporation.. 
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The  Architecture  Specification 
Model  Relates  Architecture 
Entities  to  Six  Interrogatives 


Event 

When  A 

triggers 

Figure  1.  High  Level  Structure  of  Basic  Components  of  the  ASM 

To  address  the  specific  needs  of  the  NCOE  CBA  and  using  the  basic  logic  of  the  ASM 
model  as  a  basis  and  information  and  information  sharing  as  the  context  for  analysis,  the 
authors  postulated  a  high  level  relationship  model  to  describe  the  components  of  the 
DoD’s  net-centric  Global  Information  Grid  (GIG).  As  shown  in  Figure  2,  the  architecture 
objects  “above”  the  dotted  line  represent  the  operations  or  business  artifacts  within  the 
GIG  that  are  directly  related  to  accomplishment  of  military  missions,  while  the  objects 
“below”  the  line  represent  infrastructural  services  that  enable  the  operations  to  be 
performed.  Information  Assurance  (IA),  consisting  of  both  operational  and  infrastructure 
components,  has  direct  linkages  to  every  other  component,  so  it  has  been  shown  as  a 
backdrop  to  the  other  objects. 


5 

17  February  2006 

The  MITRE  Corporation,  McLean,  Virginia 


Version  1.0 


Information 

Assurance 

Protects 


Missions 


Accomplish 


Produce  • 


Effects 


V 


Use 


User  Applications 


Activities 


t 

Produce/Consume 


Perform 


Operational 

Entities* 


Global 

Enterprise  Mgt 


Manages 


*  People  or  Equipment 


Figure  2.  A  Global  Information  Grid  Conceptual  Model 


Using  the  GIG  model  as  a  basis  for  analysis,  the  authors  selected  one  of  the 
illustrative  examples  of  the  use  of  the  Net-Centric  Operations  Environment  (NCOE) 
presented  in  the  NCOE  Joint  Integrating  Concept  (JIC),  as  a  sample  problem  set  to  which 
the  analytical  process  is  applied.  The  selected,  illustrative  example  represents  operational 
support  for  dynamic  targeting. 

The  first  challenge  faced  by  the  team  was  the  lack  of  detail  specified  in  the  NCOE 
JIC,  upon  which  analyses  could  be  conducted.  To  fill  this  gap,  the  team  turned  to  other 
documents,  such  as  the  Joint  Battle  Management  Command  and  Control  (JBMC2) 
Roadmap,  and  other  source  materials  for  additional  details.  These  documents  identify  , 
six  generic  activities  related  to  the  targeting  process:  Find,  Fix,  Track,  Target,  Engage, 
and  Assess  (F2T2EA).  These  F2T2EA  activities  can  be  summarized  as  follows: 

•  Find  -  look  for  and  detect  a  potential  target 

•  Fix  -  locate,  identify,  and  characterize  the  potential  target 

•  Track  -  maintain  continuous  cognizance  of  the  status  and  location  of  the  target 

•  Target  -  determine  options  to  pursue  and  select  the  best  method  of  attacking  the 
target 
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•  Engage  -  direct  forces  to  attack  the  target  and  follow  through  on  the  direction 

•  Assess  -  determine  what  impact  the  attack  had  on  the  target 

Furthermore,  these  activities  may  be  performed  in  a  combination  of  sequential  and 
parallel  activities,  thereby  reflecting  both  the  traditional  and  net-centric  approaches. 

To  this  end,  the  team  developed  two  “animated”  high  level  activity  models  (OV-ls)  to 
contrast  a  sequential  approach  to  accomplishing  F2T2EA  (where  information  flows  in 
turn  from  one  operational  entity  to  another)  with  a  more  net-centric  approach,  wherein 
information  is  shared  via  common  information  pools,  which  provide  operational  entities 
with  speedier  access  to  information. 

Recognizing  that  the  DoDAF’s  use  of  operational  node  connectivity  diagrams  (OV-2s) 
and  information  exchange  matrices  (OV-3s)  may  lead  readers  to  think  only  in  terms  of 
“point-to-point”  information  exchanges,  the  team  devised  a  set  of  diagrams  that  more 
readily  depict  information  flows  in  a  net-centric  environment.  This  combined  “OV-2/3” 
concept  is  depicted  in  Figure  3. 


Figure  3.  Notional  Activity-Based  Net-Centric  OV-2/3  Diagram 
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Using  this  diagram  as  a  model,  the  team  proceeded  to  identify  major  categories  of 
information  (e.g.,  situation,  friendly  force,  enemy  force,  environment,  etc.)  to  be  provided 
by  each  of  the  relevant  types  of  operational  entities  (i.e.,  sensors,  deciders,  shooters) 
involved  in  the  TST  process.  The  team  also  identified  candidate  communications 
capabilities  and  enterprise  services  associated  with  TST.  As  a  validation  of  the  overall 
GIG  model  concept  as  a  framework  for  the  analysis,  these  entities  were  overlaid  on  the 
GIG  model,  as  depicted  in  Figure  4,  wherein  the  boxes  in  bold  outlines  represent  those 
elements  of  the  GIG  model  that  were  considered  as  part  of  the  NCOE 
Baseline/Investment  Plan  effort,  and  the  elements  in  red  text  represent  those  that  could  be 
included  as  part  of  the  thin  thread  analysis. 
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Figure  4.  GIG  Model  with  NCOE-Relevant  Elements  Considered  for  Thin  Thread 


INITIAL  ANALYSIS 

An  initial  set  of  analyses  was  conducted  by  focusing  on  the  Targeting  phase  of  the 
F2T2EA  process  described  above  and  by  focusing  on  only  selected  elements  of  the  GIG 
infrastructure  that  would  support  that  phase.  In  support  of  the  analyses,  a  more  formal 
Entity-Relationship  (E-R)  diagram  was  developed  to  describe  a  selected  subset  of  the 
elements  in  the  GIG  model  presented  above.  This  diagram  is  displayed  in  Figure  5. 
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Accomplishes 


APPLICATION  ACTIVITY  OPERATIONAL-ENTITY 


Figure  5.  Entity  Relationship  Model  of  Selected  GIG  Elements 

The  relationships  defined  in  this  E-R  model  were  then  translated  into  a  set  of  pair-wise 
relationships  among  each  of  the  entities  that  could  be  implemented  in  a  series  of 
spreadsheet  tables.  The  layout  of  these  pair-wise  relationships  is  depicted  in  Figure  6. 
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Figure  6.  Pair-Wise  Thin-Thread  Linkages  Among  GIG  Entities 

For  the  initial  thin  thread  analyses,  an  MS  Excel  spreadsheet  was  developed  to  identify 
and  enable  tracing  of  the  relationships  from  a  specific  desired  operational  effect  (reduce 
the  threat  posed  by  time-sensitive  targets)  through  the  GIG  model  to  the  enterprise 
services  required  and  the  communications  infrastructure  needed  to  support  delivery  of  the 
desired  effect.  The  actual  spreadsheet  is  presented  in  Appendix  A.  The  instantiation  of 
the  relationships  was  conducted  only  at  a  very  high  level  on  detail  to  permit  manual  and 
visual  tracing  of  the  relationships  through  the  link  tables. 

However,  even  this  gross  level  instantiation  of  the  relationships  for  the  TST  Thin  Thread 
example  required  defining  activities  to  a  lower  level  than  found  in  any  available 
documentation.  Consequently,  the  specific  activities  defined  for  the  example  reflect  only 
the  opinion  of  the  authors  and  have  not  been  vetted  by  any  military  organization.  For 
example,  since  multiple  operational  entities  are  involved  in  the  activity  “Weapon-Target 
Pairing”  and  more  than  one  application  supports  this  activity,  “Weapon-Target  Pairing” 
was  hypothetically  decomposed  further  into  the  following  subactivities: 

•  Determine  Desired  Effects 

•  Determine  Constraints 

•  Determine  Target  Vulnerability 
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•  Select  Weapon 

•  Determine  Shooter  Availability 

•  Select  Shooter 

Using  this  further  level  of  decomposition,  one  could  associate  the  operational  entity 
“Sensors”  with  the  subactivity  “Determine  Target  Vulnerability”  and  the  operational 
entity  “Decider”  with  “Select  Shooter.”  Similarly,  the  application  “Blue  Force  Tracker” 
could  be  associated  with  the  subactivity  “Determine  Shooter  Availability”  and  the 
application  “Joint  Targeting  Toolkit  (JTT)”  could  be  more  easily  associated  with  “Select 
Weapon.” 

In  reality,  the  operational  entities  also  need  to  be  decomposed  into  more  granular 
components  (e.g.,  shooter  in  F-15  aircraft)  and  the  applications  need  to  be  subdivided  into 
more  granular  modules  to  really  permit  any  significant  analysis  to  be  conducted. 
Similarly,  the  other  entities  in  the  link  tables  (e.g.,  communications  connectivities, 
enterprise  services,  etc.)  also  need  to  be  further  decomposed. 

As  all  of  the  entities  are  further  decomposed,  the  ability  to  manually  and  visually  trace 
through  the  linkages  becomes  increasingly  more  difficult.  Hence  there  is  a  need  to 
capture  the  decompositions  and  the  relationships  in  an  automated  repository  that  provides 
sufficient  functionality  to  trace  through  the  linkages  to  answer  such  questions  as: 

•  What  communications  capabilities  are  needed  between  a  particular  set  of 
locations? 

•  Which  operational  entities  will  have  access  to  which  enterprise  services? 

•  What  effects  would  be  adversely  affected  by  the  loss  of  a  particular  computing 
capability? 

The  list  of  questions  can  be  infinite,  but  this  sample  reflects  those  that  must  be  addressed 
to  conduct  capabilities  based  assessments. 

In  parallel  to  development  of  linkage  tables,  the  team  also  started  to  postulate  the 
characteristics  of  the  various  elements  of  the  model  that  may  need  to  be  considered  to 
support  capabilities-based  analyses.  Candidate  characteristics  associated  with  particular 
entities  are  presented  below  with  respect  to  each  entity. 

•  “Activity”  characteristics  to  consider: 

o  Operational  Role  -  what  activities  are  performed? 
o  Criticality  -  how  important  are  the  activities? 
o  Precision  -  how  accurate  do  the  result  of  the  activity  need  to  be? 
o  Knowledge  -  what  information  is  needed  to  accomplish  the  activity? 
o  Tempo  -  how  often  is  the  activity  performed? 
o  Timeliness  -  how  fast  is  the  activity  performed? 
o  Operational  Security  -  how  much  does  it  need  to  be  protected? 

•  “Operational  Entity”  characteristics  to  consider: 

11 

17  February  2006 

The  MITRE  Corporation,  McLean,  Virginia 


Version  1.0 


o  Organizational  affiliation  -  who  are  they? 
o  Physical  location  -  where  are  they  located? 
o  Environment  -  what  kind  of  conditions  prevail  or  are  possible? 
o  Degree  of  mobility  -  how  much  do  they  move? 

•  “Community  of  Interest”  characteristics  to  consider: 

o  Community  affiliations  -  what  COIs  are  involved? 
o  Vocabulary  -  what  “language”  do  they  speak? 

•  Information”  characteristics  of  to  consider: 

o  Content  -  what  is  the  substance  of  the  info  (intel,  ops,  weather,  logistics, 
etc.)? 

o  Currency  -  when  was  it  created  or  last  updated? 
o  Perishability  -  what  is  the  “shelf  life”  of  the  information? 
o  Availability  -  can  it  be  physically  obtained? 
o  Format  -  what  form  is  it  in  (text,  audio,  video,  imagery,  etc.) 
o  Discoverability  -  is  it  tagged  and  indexed  so  it  can  be  readily  found? 
o  Accessibility  -  is  interaction  with  it  possible  and  allowed? 


RESEARCH  STATUS: 

The  research  being  conducted  under  this  project  is  still  underway.  In  parallel  with  the 
definition  of  the  thin  thread  for  NCOE  described  above,  the  authors  have  been  working 
closely  with  the  developers  of  ASM  to  further  refine  the  model  and  ensure  its  practical 
applicability  to  a  specific  problem  as  that  of  the  NCOE  CBA.  Towards  that  end,  specific 
submodels  of  ASM  are  being  defined  as  described  below. 

For  example,  a  capability  model  based  on  a  sub-set  of  the  ASM  object  classes  is  shown  in 
Figure  7.  This  model  describes  the  effect,  tasks  (functions),  conditions  and  performance 
objects,  with  their  relationships,  as  the  architectural  framework  for  capability-based 
planning.  A  complicating  factor  is  that  most  effects  and  capabilities  are  currently  being 
described  in  traditional  operational  terms.  For  example,  an  effect  might  be  “establish  air 
superiority”  and  an  associated  capability  might  be  “the  ability  to  neutralize  ground-based 
time  sensitive  targets”.  The  problem  is  to  describe  the  relationship  between  an  enabling 
capability,  such  as  some  IT  capability,  and  one  or  more  of  the  traditional  operational 
capabilities. 

The  assertion  of  the  authors  is  that  association  between  capabilities,  particularly 
when  the  capabilities  cross  functional  boundaries,  is  best  established  at  the  task  level. 

The  first  step  is  to  identify  the  dependencies  between  the  tasks  in  the  primary  capability 
and  enabling,  or  supporting,  tasks  that  have  been  defined  for  a  supporting  capability. 

Next,  a  well  defined  set  of  operational  conditions  and  task  performance  criteria  should  be 
established  for  the  primary  capability  which  can  in  turn  be  used  to  establish  a  set  of 
enabling  tasks  with  associated  performance  criteria  for  external  supporting  tasks.  In 
general,  a  minimum  set  of  operational  tasks  and  perfonnance  criteria  are  included  in  the 
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supporting  capability  architectural  model  to  show  relational  dependency  and  establish 
performance  rules  for  enabling  task  performance. 


Figure  7.  ASM  Capability  Model 


The  ASM  model  shown  in  Figure  8  depicts  FunctionPrecedesFunction  and 
Action  AssertionRule  classes.  In  this  figure,  the  external  functions  and  rules  come  from 
the  operational  capability.  The  FunctionPrecedesFunction  class  may  also  be  applied  to 
external  functions  as  “ExtemalFunctionPreceeesFunction”  to  describe  the  relationship 
between  external  and  external  tasks.  Similarly,  the  Action  AssertionRule  class  may  also 
be  instantiated  as  “ExternalActionAssertionRule”  to  establish  the  relationship  of  external 
rules  to  task  performance.  The  work  accomplished  to  date  under  this  project  was  focused 
on  investigating  the  attributes  required  for  the  external  class  objects  to  establish  the 
relationships  between  operational  tasks  and  enabling  tasks.  Specifically,  this  was  further 
scoped  down  to  information  and  information  sharing. 
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Figure  8.  ASM  Function  Process  Model 


The  team  is  now  proceeding  to  research  the  implementation  of  the  relationships  in  an 
automated  tool  with  the  intent  of  testing  the  use  of  the  tool  to  answer  selected  questions 
as  posed  above.  Two  tools  are  being  considered.  The  first  is  Vitech’s  CORE  software.  It 
is  being  closely  examined  for  three  reasons:  first,  it  already  contains  pre-scripted  queries 
that  mirror  some  of  the  ones  needed  to  answer  some  candidate  questions,  second,  its 
internal  tables  can  be  easily  modified  to  accommodate  the  specific  entities  defined  for  the 
GIG  model,  and  third,  it  has  a  modeling  and  simulation  capability.  The  other  tool  being 
considered  is  Troux’s  Metis  software,  principally  because  of  its  graphical  interface  that 
facilitates  presentation  of  analytical  results. 
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APPENDIX  A 

NCOE  Thin  Thread  Analysis  Link  Table 

The  following  pages  present  the  initial  linkages  detennined  for  the  NCOE  Thin  Thread 
Analysis.  The  “Xs”  in  the  cells  indicate  that  a  relationship  of  some  sort  exists  between 
the  elements  identified  in  the  particular  row  and  column  of  the  spreadsheet.  The  specific 
linkages  presented  are  as  follows: 

Table  A-l.  Which  Missions  Produce  What  Effects 

Table  A-2.  Which  Missions  are  Accomplished  by  What  Activities 

Table  A-3.  Which  Operational  Entities  Perform  What  Activities 

Table  A-4..  To  Which  COIs  do  What  Operational  Entities  Belong 

Table  A-5.  Which  Information  is  Needed  for  What  Activities 

Table  A-6.  What  COIs  Share  What  Information 

Table  A-l .  Which  Applications  Process  What  Information 

Table  A-8.  Which  Applications  Use  What  Core  Services 

Table  A-9.  Which  Cores  Services  Require  What  Communications 

Table  A- 10.  Which  Communications  Connects  What  Locations 

The  blue  shading  indicates  specific  relationships  that  have  been  identified  for  this 
analysis.  As  can  be  seen,  the  spreadsheet  is  still  a  work  in  progress  and  not  all  of  the 
linkages  have  yet  to  be  identified. 
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Missions 


Which  Missions  Produce  What  Effects 

Prosecute 

TST 

Reduce  Threat 

X 

Table  A-l.  Which  Missions  Produce  What  Effects 


Missions 


Which  Missions  are  Accomplished  by 
What  Activities 

Prosecute  TST 

Find 

X 

Fix 

X 

Track 

X 

Target 

X 

Weapon-Target  Pairing 

X 

Determine  Desired  Effects 

X 

Determine  Constraints 

X 

Determine  Target  Vulnerability 

X 

Select  Weapon 

X 

Determine  Shooter  Availability 

X 

Select  Shooter 

Engage 

X 

Assess 

X 

Table  A-2.  Which  Missions  are  Accomplished  by  What  Activities 
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Operational  Entities 


Which  Operational  Entities  Perform 
What  Activities 

Sensor 

Decider 

Shooter 

Find 

Fix 

Track 

Target 

Weapon-Target  Pairing 

Determine  Desired  Effects 

X 

Determine  Constraints 

X 

Determine  Target  Vulnerability 

X 

Select  Weapon 

X 

Determine  Shooter  Availability 

X 

X 

Select  Shooter 

X 

Engage 

Assess 

Table  A-3.  Which  Operational  Entities  Perform  What  Activities 


Operational  Entities 


To  Which  COIs  do  What  Operational 
Entities  Belong 

Sensor 

Decider 

Shooter 

Intelligence 

X 

Logistics 

X 

X 

X 

Medical 

Operations 

X 

X 

TST 

X 

X 

X 

Weather 

X 

X 

X 

Table  A-4.  To  Which  COIs  do  What  Operational  Entities  Belong 
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Information 


Which  Information  is  Needed  for 
What  Activities 

Situation 

Environment 

Objectives 

Enemy 

Friendly 

Find 

Fix 

Track 

Target 

Weapon-Target  Pairing 

Determine  Desired  Effects 

X 

X 

Determine  Constraints 

X 

X 

X 

X 

Determine  Target  Vulnerability 

X 

X 

Select  Weapon 

X 

X 

X 

X 

Determine  Shooter  Availability 

X 

X 

Select  Shooter 

X 

X 

X 

Engage 

Assess 

Table  A-5.  Which  Information  is  Needed  for  What  Activities 


Information 


Which  COIs  Share  What 
Information 

Situation 

Environment 

Objectives 

Enemy 

Friendly 

Intelligence 

X 

Logistics 

X 

Medical 

Operations 

X 

TST 

X 

X 

Weather 

X 

Table  A-6.  What  COIs  Share  What  Information 
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Applications 


Which  Applications  Process 
What  Information 

i — 
u_ 
m 

i— 

t— 

~ 3 

GCCS COP 

Situation 

X 

Environment 

X 

Objectives 

X 

Enemy 

X 

Friendly 

X 

X 

Table  A-7.  Which  Applications  Process  What  Information 


Applications 


Which  Applications  Use  What  Core 
Services 

BFT 

H 

H 

—> 

GCCS  COP 

Video  over  IP 

Voice  over  IP 

M-to-M  messaging 

Mediation 

Service  security 

Data  source  integration 

Session  Mgt 

Service  security 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Table  A-8.  Which  Applications  Use  What  Core  Services 
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Core  Services 


Which  Core 
Services  Require 
What  Comms 

Video  over  IP 

Voice  over  IP 

M-to-M  messaging 

Mediation 

Service  security 

Data  source  integration 

Session  Mgt 

Service  security 

Very  High  Capacity 
Terrestrial 

X 

X 

X 

X 

X 

IP-Enabled  LOS  RF 

X 

X 

X 

X 

X 

Satellite  to  Terrestrial 
Gateway 

X 

X 

X 

X 

X 

Satellite 

X 

X 

X 

X 

X 

Table  A-9.  Which  Cores  Services  Require  What  Communications 


Locations 


Which 

Communications 
Connects  What 
Locations 

CONUS-Large 

OCONUS-GIG-BE 

OCONUS-Other 

Major  Deployed 

Airborne  -  C4ISR 

Airborne  -  Shooter 

Airborne  -  Mobility 

Land  Mobile  -Vehicular 

Land  Mobile  -Dismounted 

Maritime  -large 

Maritime  -Medium 

Maritime  -  small 

Very  High  Capacity 
Terrestrial 

X 

X 

IP-Enabled  LOS  RF 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Satellite  to  Terrestrial 
Gateway 

X 

X 

Satellite 

X 

X 

X 

X 

X 

X 

X 

X 

Table  A-10.  Which  Communications  Connects  What  Locations 
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